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selection.  We  illustrate  the  approach  with  several  tutors  implemented  in  our  lab. 
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Introduction 


Many  projects  in  intelligent  computer-based  instruction  depend  upon  detailed  but  general 
theories  of  human  learning  or  diagnoses  of  the  learner's  cognitive  state  (see,  for  example,  Bonar  and 
Cunningham  [1986],  Ohlsson  and  Langley  [1984]  and  Van  Lehn  [1984]).  We  feel  there  is  also  an 
enormous  potential  for  systems  based  on  theory-driven  analyses  of  domain  expertise.  For  particular 
fields,  for  example,  cognitive  science  researchers  have  developed  accounts  of  skilled  performance  and 
of  impediments  to  skilled  performance.  Such  accounts  could  be  used  to  develop  useful  and  interesting 
instructional  systems.  Widespread  development  of  this  kind  of  tutor  would  be  faciliated  by  a  general 
intelligent  tutoring  system  architecture  and  tools  to  support  development.  In  this  paper  we  desribe 
our  first  steps  toward  such  an  architecture,  called  the  Bite-Size  Tutor. 

The  Bite-Size  Tutor  is  a  general  intelligent  tutoring  system  shell  that  provides  the 
curriculum-independent  part  of  an  intelligent  tutor  and  specifies  an  organization  for  the  curriculum 
knowledge,  to  be  supplied  by  a  domain  expert.  With  the  Bite-Sized  Tutor,  .we  can  exploit  the  expert 
system  approach  currently  being  applied  in  many  intelligent  tutoring  system  projects.  In  this 
approach,  competent  performance  in  a  domain  is  analyzed.  Novices  learning  that  domain  may  be 
observed.  The  results  of  these  analyses  and  observations  are  a  "cognitive  task  analysis"  of  the  domain 
and  a  "bug  catalog"  of  common  novice  problems  in  the  domain.  "Cognitive  task  analyses"  (Learning 
Research  &  Development  Center,  May  1986)  are  analyses  beyond  a  behavioral  "rational  task 
analysis"  that  specifically  attend  to  the  underlying  cognitive  skills  and  representations  involved  in 
competent  performance.  "Bug  catalogues"  (Brown  &  Burton,  1973;  VanLehn,  1982,  1983)  describe 
systematic  errors  or  misconceptions  that  are  likely  to  impede  learning  or  skilled  performance  Taken 
together,  the  cognitive  task  analysis  and  the  bug  catalog  constitute  the  "curriculum"  of  most 
intelligent  tutors. 

Our  key  goal  with  the  Bite-Size  Tutor  is  an  interface  that  allows  the  curriculum  of  a  system  to 
be  supplied  by  a  domain  expert  who  is  not  a  programming  expert.  This  is  a  crucial  goal  —  creating  the 
curriculum  for  any  kind  of  computer  based  instruction  is  a  demanding  and  time  consuming  task, 
running  into  hundreds  of  hours  of  development  for  each  hour  of  instruction  The  toy  domains, 
microscopic  curriculums,  and  limited  instructional  activities  of  experimental  intelligent  tutors  must 
be  expanded  to  complete  curriculums  that  meet  recognized  instructional  needs  with  an  array  of 
techniques  and  activities  for  the  student.  Such  an  expansion  requires  extensive  input  by  domain 
experts  who  are  not  programmers.  We  in  the  intelligent  tutoring  community  must  provide  the  tools  to 
allow  this  approach. 


In  this  article,  we  first  discuss  problems  with  current  intelligent  tutoring  system 
architectures.  We  then  propose  our  solution:  an  architecture  that  uses  the  structures  of  an 
object-oriented  programming  language  as  domain-independent  modules  for  intelligent  tutors.  We 
discuss  the  detailed  architecture  of  the  Bite-Size  Tutor,  and  illustrate  this  architecture  with  several 
examples  from  projects  being  developed  at  LRDC.  Finally,  we  touch  upon  future  research  directions. 

Problems  with  current  intelligent  tutoring  systems 

Close  examination  of  most  current  intelligent  tutoring  system  implementations  shows  them 
to  be  complex  and  unwieldy.  (We  want  to  emphasize  that  this  discussion  is  not  a  criticism  of  any 
particular  intelligent  tutoring  system,  but  a  general  problem  that  appears  in  many  systems.)  Pieces  of 
programming  code  are  repeated  in  several  places;  closely-related  information  is  spread  apart.  It  might 
appear  that  these  difficulties  are  simply  a  matter  of  prototype  implementations,  written  without 
concern  for  detailed  software  engineering  issues.  While  this  is  part  of  the  problem,  there  is  a  more 
fundamental  design  flaw,  related  to  the  use  of  knowledge  within  the  intelligent  tutoring  system. 
Intelligent  tutoring  systems  are  usually  conceived  as  a  series  of  semi-independent  components  like 
"explainer,"  "diagnoser,"  "tutor,"  and  "user  modeler."  The  problem  is  that  these  components  need  to 
share  many  diverse  pieces  of  knowledge.  The  knowledge  needed  for  different  components  typically 
overlaps  considerably.  Functional  components  whose  roles  are  quite  clearly  delineated  in  an  abstract 
description  of  the  system  may  be  implemented  with  code  diffused  through  many  parts  of  the  system. 
The  systems,  therefore,  are  not  modular.  In  po’ticular,  they  do  not  allow  for  addition  of  new  domain 
knowledge  or  new  approaches  to  the  pedagogical  tasks. 

The  WEST  tutor  [Brown  and  Burton,  1982 j  provides  an  example  of  these  problems.  As  one  of 
the  most  intellectually  important  "classic"  intelligent  tutoring  systems,  it  serves  as  a  useful  foil  for 
this  discussion  It  can  be  viewed  in  two  ways:  in  terms  of  its  "issues"  (the  fundamental  lessons  the 
system  is  prepared  to  teach  the  student)  and  in  terms  of  its  components  (e  g.  "expert,"  "differential 
modeler,"  "tutorial  selector  ")  In  the  actual  Interlisp-D  implementation  of  the  tutor,  the  program  is 
organized  by  components  This  results  in  a  system  with  unnecessary  duplication  and  complexity  in  its 
multiple,  overlapping  representations  of  issue  knowledge.  Besides  obscuring  the  organization  of  its 
knowledge,  the  current  implementation  of  WEST  makes  it  difficult  to  reuse  and  extend  parts  of  the 
tutor.  Given  the  many  open  research  issues  for  intelligent  tutoring  systems,  this  is  a  serious  problem. 

In  general,  we  need  a  tool  that  enables  the  development  of  tutoring  systems  much  more 
rapidly  than  now  possible.  Ideally,  such  a  tool  will  allow  a  subject  domain  expert  or  a  teacher  (who  is 
not  necessarily  a  programmer)  to  modify  the  domain  knowledge  and  the  tutor-student  interaction 
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without  reimplementing  the  system  at  each  step.  Finally,  we  need  a  tool  to  make  it  easier  for  those 
who  develop  tutors  to  test  their  systems  as  they  are  designed. 


An  Object-Oriented  Intelligent  Tutoring  System  Architecture 

We  propose  to  take  advantage  of  the  character  of  an  object-oriented  programming  language  to 
develop  an  architecture  that  is  modular  and  is  therefore  both  comprehensible  and  easily  modified. 
Object-oriented  programming  allows  the  programmer  to  create  a  toolkit  of  objects  that  repi  esent  items 
of  interest  in  the  application  area  of  the  program.  Objects  represent  items  in  the  world  by  containing 
both  data,  the  state  of  the  object,  and  programs,  operations  that  can  change  the  state.  Objects  can  also 
share  structure,  with  one  object  defining  the  structure  for  several  other  objects.  Such  an  object  is 
called  a  class.  Typically  an  object  specializes  a  structure  it  inherits  from  above,  and  in  turn  defines  the 
structure  for  a  lower-level  set  of  objects.  An  object  communicates  by  sending  a  message  to  another 
object  and  requesting  some  action  An  object  responds  to  a  message  by  running  one  of  its  programs, 
thereby  changing  its  state  or  sending  new  messages  to  other  objects. 

Although  objects,  classes,  inheritance,  and  messages  are  the  crucial  constructs  of 
object-oriented  programming,  the  notions  of  toolkit  and  protocol  are  central  to  understanding  the 
power  of  the  approach.  A  toolkit  provides  a  set  of  objects  designed  to  be  specialized  and  protocols  for 
using  those  objects.  Objects  in  a  toolkit  provide  a  range  of  capabilities  designed  to  be  specialized  to 
particular  applications.  A  protocol,  in  the  object-oriented  sense,  is  a  set  of  messages  that  are  defined 
for  a  broad  range  of  objects.  For  example,  we  could  design  a  drawing  system  where  objects 
corresponding  to  rectangles,  circles,  and  characters  all  responded  to  the  messages  draw,  erase,  move, 
etc.  Note  that  each  kind  of  object  is  free  to  implement  these  messages  differently.  This  is  the  essence 
of  a  protocol:  a  general  set  of  capabilities  for  simplicity,  with  a  mechanism  for  accommodating  the 
complexity  of  actual  differences. 

The  Bite-Size  architecture  is  a  toolkit  for  implementing  intelligent  tutors.  In  the  Bite-Size 
architecture,  everything  the  system  knows  is  stored  in  objects.  Some  of  these  objects  will  correspond  to 
"issues"  in  the  sense  used  by  Burton  and  Brown  (1982):  things  that  the  system  can  understand  and 
talk  to  the  user  about.  Many  of  the  different  objects  representing  the  domain  will  share  common 
substructure.  For  such  objects,  the  standard  class  inheritance  mechanisms  of  object-oriented 
programming  are  appropriately  used  The  critical  point  is  that  every  thing  the  system  will  interact 
with  the  user  about  is  a  separate  class.  We  call  these  domain  knowledge  classes  Bites.  They  are  all 
subclasses  of  the  class  Bite. 

Given  that  we  organize  the  system  on  the  basis  of  the  issues  that  the  system  recognizes,  where 
are  we  to  put  components  of  the  tutor  like  the  "diagnoser,"  "student  mocel,"  and  "task  selector"?  We 


provide  these  components  in  a  generic  form  as  high  level  objects.  So,  for  example,  there  are  objects 
that  can  implement  a  component  like  a  diagnoser.  The  class  Diagnoser  will  specify  the  local  data 
needed  to  perform  the  diagnostic  function  and  the  algorithms  to  use  that  data.  The  Diagnoser  class 
specification  does  not  specify  any  particular  diagnosis  to  be  done,  only  the  general  procedure  and  data 
required  for  doing  a  diagnosis. 

The  specific  data  needed  for  performing  an  actual  diagnosis  are  provided  when  the  general 
component  classes  (e.g.  the  Diagnoser  class  just  discussed)  are  inherited  by  the  Bite  classes  that 
actually  need  to  use  them.  Similarly,  the  other  standard  intelligent  tutoring  system  components  are 
implemented  as  classes  and  inherited  by  the  Bites.  Consider  an  example  where  two  kinds  of 
diagnosers  are  to  accomplish  two  styles  of  diagnosis.  This  would  be  handled  by  having  the  general 
properties  of  diagnosers  in  a  class  Diagnoser  with  the  specific  properties  contained  in  two  subclasses 
DiagnoserA  and  DiagnoserB.  Bites  are  specified  to  inherit  their  diagnostic  capability  from 
DiagnoserA  or  DiagnoserB  as  appropriate. 

The  proposed  architecture  solves  the  problems  described  above  by  making  the  system  highly 
modular.  Each  curriculum  element  is  represented  explicitly  as  a  class.  To  the  extent  that  curriculum 
elements  share  structure,  that  sharing  is  explicitly  represented  in  the  inheritance  among  the  classes 
representing  these  elements.  Similarly,  each  of  the  key  tutoring  components  is  represented  as  a  class 
object.  These  component  classes  are  used  to  provide  tutoring  function  to  the  domain  classes.  Like  the 
domain  element  classes,  component  classes  use  inheritance  to  represent  shared  structure. 


The  Curriculum  Elements:  Bites 

The  structure  of  the  classes  representing  curriculum  element  bites  is  defined  by  inheritance 
from  two  kinds  of  classes.  Tutoring  component  classes,  such  as  the  student  model  and  the  diagnoser, 
provide  a  framework  in  which  data  must  be  supplied  by  the  implementer  or  curriculum  designer.  We 
plan  to  build  a  non-programming  interface  to  facilitate  defining  these  bites.  Bites  also  inherit 
structure  based  on  the  kind  of  knowledge  they  represent.  We  have  defined  several  classes  of  bites: 
Abstraction  Hierarchy  Bites,  Definition  Bites,  Input/Output  Bites,  and  Discovery  Bites  In  this 
section  we  discuss  each  in  detail. 

An  abstraction  hierarchy  represents  an  ordering  of  concepts  in  the  curriculum.  In  this 
hierarchy  specific  versions  of  a  concept  appear  at  the  lowest  level  of  the  hierarchy  and  more  general 
versions  of  that  concept  appear  higher  in  the  hierarchy.  An  example  of  this  is  shown  in  Figure  1 
There  we  see  the  abstraction  hierarchies  for  Ohm's  Law  and  KirchholTs  Law  from  our  electricity  tutor 
The  two  highlighted  nodes  show  the  relationship  between  the  specific  concept,  "current  is  unchanged 
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across  an  uninterupted  wire,"  and  the  more  general  concept,  "Kirchhoffs  Law."  The  "UninterruptedS" 
bite  is  a  specific  version  of  the  "KirchoffsLaw"  bite  and  thus  is  shown  at  a  lower  position  in  the 
hierarchy. 


Abstraction  hierarchy  bites  play  an  important  organizing  role  in  the  tutors.  These  bites 
exercise  a  range  of  simpler  ideas  in  the  curriculum.  In  electricity,  for  example,  understanding 
KirchhofPs  Law  implies  understanding  a  collection  of  more  fundamental  ideas:  circuit  geometry  (e.g. 
parallel  vs.  series),  resistor  behavior,  battery  behavior,  current,  resistance,  and  voltage.  Because  of 
this  organizing  role,  the  problems  abstraction  hierarchy  bites  generate  are  critical  for  the  diagnosis  of 
student  performance.  Only  abstraction  hierarchy  bites  have  sufficient  perspective  (i.e.  connection  to 
other  bites  representing  fundamental  ideas)  to  test  the  student's  performance  in  problems  that 
integrate  across  several  bites  (Lesgold  &  Ivill,  1987).  Implementing  this  perspective  is  a  current  area 
of  active  research.  Our  initial  work  is  presented  in  the  section  on  tutoring  components. 
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Figure  l.  Abstraction  Hierarchy  from  tho  Electricity  Tutor 


Definition  Bites  represent  concepts  that  the  student  is  to  learn  without  being  taught  much 
background.  Examples  of  this  would  be  the  concept  of  gravitational  force  as  it  is  used  in  our  tutor  for 
hydrostatics  (Archimedes's  Principle).  It's  important  for  the  student  dealing  with  buoyancy  to 
understand  how  gravity  works.,  but  it's  nor.  important  to  know  wh  v  it  works  that  wav. 


Input/Output  Bites  represent  concepts  that  have  a  black-box  behavior.  The  student  needs  to 
know  that  certain  inputs  produce  certain  outputs  and  needs  to  know  the  rule  (formula)  describing  the 
behavior.  The  student  does  not  need  to  know  the  justification  for  the  behavior.  The  behavior  of  a 
resistor  in  an  electric  circuit  is  best  represented  in  an  I/O  bite. 
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Discovery  Bites  enable  several  of  our  tutors  to  combine  the  advantages  of  student-initiated 
learning  in  discovery  worlds  with  support  for  students  who  lack  the  skills  to  learn  efficiently  from  a 
pure  discovery  world.  These  tutors  provide  a  simulation  of  some  aspect  of  a  domain.  The  intelligent 
tutoring  system  allows  the  student  to  explore  the  simulation  freely  until  it  decides  the  student  is 
floundering,  then  it  makes  a  suggestion.  Discovery  Bites  represent  the  inquiry  skills.  An  example  of 
this  type  of  bite  is  "vary  only  one  variable  while  holding  all  else  constant."  [Shute  and  Bonar,  1986]. 

Tutoring  Components:  Diagnoser 

There  are  three  main  tutoring  components  of  the  bite-sized  tutoring  architecture:  the 
Diagnoser,  the  Student  Model,  and  the  Task  Selector.  We  discuss  each  component  in  turn.  The 
Diagnoser  is  invoked  by  some  event  that  occurs  during  the  tutoring  session.  The  implementor  of  a 
specific  tutor  determines  what  events  invoke  the  Diagnoser.  In  particular,  we  want  to  allow  for 
different  grain-sized  observations  of  the  student,  ranging  from  making  a  diagnosis  only  when  a 
student  completes  a  problem  to  making  a  diagnosis  based  on  the  student's  movement  of  the  mouse 
every  n  milliseconds. 

The  Diagnoser  class  is  best  illustrated  in  our  implementation  of  the  Electricity  tutor.  Consider 
what  happens  svhen  a  student  responds  to  a  problem  constructed  at  some  intermediate  bite  in  the 
Kirchhoffs  Law  abstraction  hierarchy.  That  problem  has  been  constructed  from  a  number  of 
component  bites  representing  the  fundamentals  needed  to  understand  the  abstraction  hierarchy  bite. 
For  example,  a  bite  in  the  Kirchhoffs  Law  abstraction  hierarchy  constructs  problems  based  on 
component  bites  concerning  resistors,  current,  circuit  geometry,  etc. 

Once  the  system  has  a  student  response  to  a  problem,  the  abstraction  hierarchy  bite  begins  a 
diagnosis.  Using  capabilities  provided  by  the  Diagnoser  class,  the  bite  sends  a  message  to  each 
component  bite  asking  if  the  domain  knowledge  in  the  component  bite  is  relevant  to  the  student's 
response,  current  tutoring  goals,  and  the  current  tutoring  mode.  If  it  is,  the  Diagnoser  then  checks  to 
see  if  the  student  is  misusing  the  concept  taught  by  this  bite.  "Misuse"  is  defined  by  a  specific 
diagnosis  algorithm  operating  on  the  specific  data  of  that  bite.  The  Diagnoser  then  updates  the 
student  model  accordingly.  Note  that  the  data  for  the  student  model  are.  of  course,  stored  in  the  bites. 
When  the  Diagnoser  has  completed  updating  the  bites,  it  invokes  the  Task  Selector  to  choose  what  it 
should  do  next. 


Tutoring  Components:  The  Student  Model 
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The  Student  Model  maintains  several  components  relevant  to  representing  student 
performance.  First,  the  Student  Model  contains  a  record  of  the  e\cr>ts  of  the  session.  This  is  stored  in  a 
class  variable  of  the  Bite  class  so  that  all  curriculum  bites  (which  are  instances  of  subclasses  of  Bite) 
have  access  to  one  copy  of  it.  In  addition,  the  Student  Model  specifies  a  sei  ies  of  instance  variables 
that  represent  student  performance  on  individual  bites.  We  currently  use  a  differential  modeling 
scheme  where  we  keep  three  separate  measures  of  the  student's  success  with  each  bite  One  is  a 
measure  over  the  entire  tutoring  session,  one  is  a  measure  over  the  the  last  five  events,  and  the  last  is 
a  measure  of  the  last  (or  current)  event.  These  measures  are  ratios  of  how  many  times  the  concept  of 
each  bite  was  used  appropriately  by  the  student,  divided  by  how  many  times  it  should  have  been  used 
as  determined  by  the  Diagnoser. 

Tutoring  Components:  The  Task  Selector 

The  basic  flow  of  control  of  the  tutor  is  based  on  Tutoring  Mode  objects  stored  in  a  stack  located 
in  a  global  object  Tutoring  Session.  Tutoring  Mode  instances  set  the  local  state  for  a  series  of 
instructional  tasks.  The  Tutoring  Mode  has  two  instance  variables  useful  to  the  Task  Selector.  One 
indicates  criteria  for  the  mode  being  satisfied,  and  one  indicates  some  threshold  for  deciding  that  the 
student  is  floundering  and  currently  unable  to  learn  the  current  concept  in  the  current  mode. 

Fach  mode  object  defines  several  messages.  The  Initialization  message  initializes  the  two 
instance  variables  mentioned  above,  based  on  the  current  student  model.  A  Process  message  teaches 
the  relevant  bites  in  a  manner  consistent  with  the  current  mode  (see  below).  A  Satisfaction  message 
will  determine  if  the  current  mode  is  satisfied  and  what  steps  are  to  be  taken  when  it  is.  It  usually 
means  popping  the  present  mode  instance  off  the  Tutoring  Session  stack  and  pushing  a  new  mode 
instance  on  the  stack.  A  Threshold  message  decides  what  actions  to  take  when  the  student  shows 
evidence  of  not  being  able  to  satisfy  the  mode  object.  This  will  usually  initiate  pushing  some  remedial 
mode  object  onto  the  stack. 

The  Task  Selector  first  examines  the  stack.  If  it  is  empty  the  Task  Selector  creates  a  new 
instance  of  some  default  mode  and  sends  the  local  Initialization  message  to  the  mode.  The  Task 
Selector  then  returns  the  control  to  the  student.  If  the  stack  is  not  empty,  the  Task  Selector  sends  the 
Satisfaction  message  If  the  current  mode  is  not  satisfied,  the  Threshold  message  is  then  sent.  Finally, 
if  the  threshold  condition  is  not  met  the  Process  message  is  sent. 

Tutoring  modes  describe  the  type  of  tutor-student  interaction  that  is  currently  being  used.  We 
are  implementing  six  of  these  modes: 


-Exploration  -  The  student  is  obtaining  information  from  the  discovery  world  in 
order  to  refine  and  complete  developing  hypotheses. 

-Experimentation  -  The  student  is  performing  some  action  designed  to  confirm  or 
differentiate  hypotheses,  whether  explicitly  stated  or  recognized  by  the  tutor. 
-Elaboration  --  The  student  is  testing  some  previously  confirmed  hypothesis. 

Didactic  -  The  tutor  is  driving  the  interaction  by  proposing  problems  for  the 
student 

-Demonstration  -  The  tutor  takes  over  and  demonstrates  some  concept  explicitly 
-Coaching  The  tutor  provides  some  hints  that  will  help  the  student  understand  the 
bites  in  question 

Example  Bite-Sized  Intelligent  Tutors 

Bridge  An  Intelligent  Tutor  for  Programming 

Bridge  is  a  tutor  that  teaches  computer  programming.  In  Bridge,  the  student  user  is  presented 
with  problems  of  a  complexity  appropriate  to  the  first  ten  weeks  of  an  introductory  programming 
course  Bridge  coaches  the  student  through  three  phases  of  problem-solving  for  each  problem  posed. 

In  the  first  phase,  the  student  constructs  a  set  of  step-by-step  instructions  by  choosing  and  arranging 
informal  English  phrases  In  the  next  phase,  the  student  matches  these  phrases  to  visual 
representations  of  programming  schemata  we  call  "plans"  [Soloway  et  al.,  1982]  and  combines  the 
representations  to  build  a  runnable  program.  In  the  final  phase,  the  student  uses  the  visual 
representation  as  a  guide  to  building  a  correct  programming  language  solution  to  the  original 
problem  Currently  Bridge  tutors  Pascal:  other  programming  languages  could  be  tutored  using  the 
same  approach 

In  the  current  Bridge  implementation  (Bonar  &  Cunningham,  1986)  the 
curriculum-dependent  bites  are  the  programming  plans  and  the  plan  specializations  needed  for  each 
problem  that  Bridge  can  tutor.  These  plans  fit  into  an  abstraction  hierarchy  with  the  problem-specific 
programming  plans  at  the  lowest  level  of  the  hierarchy.  The  Diagnoser  determines  whether  a 
particular  bite  is  being  used  appropriately  by  comparing  the  student's  current  program  with  the 
requirements  specified  for  that  plan  in  the  current  phase.  This  information  is  represented  by  a 
requirements  language  that  defines  a  group  of  operators  which  indicate  various  things  about  the 
plans,  the  correct  order  of  their  appearance,  and  their  relationships  to  each  other.  Figure  2  shows  an 
example  of  this  language.  This  example  shows  some  of  the  requirements  of  the  Counter  Variable  Plan 
in  Phase  1  for  the  Ending  Value  Averaging  Problem. 
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DEdifcof.  expression>w^-r;-?-,,,>~"-’r--.y-,v^u*-;M-'  -> 


(PushToHighest  lEVAPCounterVanad lePlan 
Exists? 

(Hints  (In  order  to  conpute  the  average, 

you  will  need  to  divide  the  sum 
of  the  integers  by  the  number  of 
integers  read  in.  Include  a  plan 
to  read  in  the  number  of 
integers. ) 

(To  compute  the  average,  you  must 
divide  the  sum  of  all  the 
integers  read  in  by  the  count  of 
the  number  of. integers.  Include 
the  %*Keep  count  of  ...  ft*  plan 
now.))) 

(EVAPCounterVariablePlan  Sequence  ... 

EVAPInputNevValueVar lablePlan  ... 

EVAPCounterVariablePlan  ... 

(Hints -\You  have  to  acquire  the  numbers 
BEFORE  you  can  count  them.) 

(Put  the  step  you  use  to  acquire  the 
numbers  above  the  step  you  use  to 
count  them.) 

(Put  ft'Keep  count  of  ...ft*  plan  below 
the  ft'Read  in  . . .ft" 

or  ft'Get  ....ft*  plan.))) 

(AnyOf  (EVAPCounterVariablePlan  Sequence  ... 

EVAPCounterVariablePlan  ... 

EVAPResulcOucputPlan  ...) 

(EVAPCounterVar lablePlan  Sequence  . v 

EVAPCounterVariablePlan  ... 

EVAPResultValuePlan  ..•. ) 

(Hints  (You  must  count  the  numbers  BEFORE  you 
can  compute  the  average.) 

(Put  the  statement  you  use  to  count 
the  numbers  higher  than  the  one 
you  use  to  compute  the  average.)) 

)) 


Figure  2.  Requirements  Language  from  Bridge 


Some  of  the  requirements  language  operators  we  have  found  useful  are: 

-Sequence  —  this  describes  the  order  in  which  the  plans  should  appear  in  the 
program.  Figure  2  shows  three  such  sequence  requirements.  The  that  separates 
some  plans  indicates  that  zero  or  more  plans  can  come  between  them  in  the 
student's  solution. 

-Exists?  -  This  operator  indicates  that  the  plan  mentioned  must  appear  in  the 
program.  In  figure  2,  the  Counter  Variable  Plan  is  required  to  be  in  the  program. 
-AnyOf  -  this  is  the  equivalent  of  an  OR  operator.  It  is  satisfied  if  any  of  its 
arguments  is  satisfied. 

-All  —  this  is  the  equivalent  of  an  AND  operator.  It  is  satisfied  only  if  all  of  its 
arguments  are  satisfied. 

-Not  —  this  is  the  usual  NOT  operator.  It  is  satisfied  only  if  its  argument  is  not 
satisfied. 

-PushToHighest  -  This  manages  several  requirements  at  once  and  selects  a  hint 
dealing  with  the  first  unsatisfied  plan. 
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Figure  3.  Bile  Hierarchy  for  Smithtown.  "tnlerrogationBile"  is  a  class  of  Discovery  Biles. 

Smithtown:  A  Discovery  World  for  Economics 

The  economics  discovery  world  simulates  an  imaginary  town  which  conforms  to  the  laws  of 
supply  and  demand.  The  student  controls  several  variables,  e  g.  population,  income  per  capita, 
interest  rates,  consumer  preference,  number  of  suppliers,  and  weather.  The  student  changes  one  or 
more  of  these  variables  and  observes  the  resultant  change  on  the  other  variables  of  the  world  The 
student  has  several  tools  to  aid  discovery,  e  g  a  notebook  to  rocord  the  changes  observed  in  *he 
variables  and  a  graph  package  to  observe  relationships  between  variables.  In  addition  to  teaching  an 
economics  curriculum,  the  tutor  teaches  scientific  discovery  skills,  so  some  of  its  bites  are  discovery 
bites  (see  Figure  3).  The  economics  curriculum  bites  will  teach  about  the  patterns  in  the  data  collected 
by  the  students  as  they  explore  the  microworld. 
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Eureka:  A  Tutor  for  Hydrostatics  Problems 


Eureka  employs  an  exploratory  microworld  environment  that  demonstrates  the  principles  of 
buoyancy  pertinent  to  Archimedes'  Principle  (Klopfer,  1985).  The  mode  of  learning  is  very  similar  to 
the  economics  tutor.  The  student  explores  the  microworld,  makes  hypotheses  when  he  or  she  discovers 
some  relationship,  and  then  tests  those  hypotheses  with  subsequent  experiments.  The  student  has  the 
ability  to  change  several  variables  in  the  "laboratory”  environment:  the  mass  of  the  block,  the  density 
of  the  liquid,  the  gravitational  force,  etc.  He  has  the  same  tools  available  to  aid  his  exploration  that 
were  described  above  in  the  economics  tutor. 


Figure  4.  Bite-Siied  Hierarchy  from  the  Eureka  Tutor 


Figure  4  shows  the  inheritance  lattice  for  Eureka.  This  tutor  is  very  similar  in  structure  to  the 
economics  tutor.  It  uses  discovery  bites  to  tutor  useful  scientific  skills.  It  has  bites  that  teach  about 
observable  patterns  in  the  data  collected  during  the  session. 
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Concluding  Remarks 


We  have  illustrated  a  generic  architecture  for  building  intelligent  tutoring  systems.  In 
particular,  we  have  focused  on  techniques  for  domain  independent  representation  of  the  knowledge  to 
be  taught.  The  key  idea  is  to  organize  the  tutor  around  objects  that  represent  the  knowledge  to  be 
taught,  not  around  the  various  components  of  the  tutor. 

Although  each  of  the  tutors  discussed  is  implemented,  very  little  code  is  actually  shared 
between  them.  We  are  currently  reimplementing  several  of  the  tutors  to  share  code  for  all  the  basic 
components  and  knowledge  organizations.  We  have  also  begun  working  with  non-programming 
domain  experts  in  designing  an  interface  to  let  them  design  the  tutor's  curriculum. 
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